The software industry has traditionally deployed automation to increase developer productivity, to improve the quality of released software, and to accelerate innovation. One such area of automation has focused on the Software Development Life Cycle (SDLC)—targeting the build, test, and release process, for improvement via automation. More generally, development in this area has focused on encouraging “best practice” software engineering. Many of these best practices originated as manual processes, and software developers soon automated them: nightly compiles, periodic performance testing, the use of “staging” environments that mimic or clone production deploy targets, unit, functional, and integration testing, and end-user testing.
The prevalence of software and the increasing pace at which software needs to change has put increasing pressure on conventional build and release processes and systems. The last generation of innovation in such systems occurred in the late 1990s and early 2000s, in the form of Continuous Integration and systems to support it. For example, a number of closed and open source tools (CruiseControl, Hudson, Bamboo, Anthill, TeamCity) were developed to help software developers implement Continuous Integration. In the abstract, a continuous integration (CI) server is associated with a Software Configuration Management (SCM) system that records source code versions for an application as they change, and further records changes in associated metadata.
The CI server is notified (actively or passively) when the SCM records a change, retrieves the latest source code and executes a user-provided script, capturing the scripts output and storing artifacts or file objects that may have been created when the script executed. In many cases, the user manually configures a script to set up the dependencies needed to build and execute the application, builds the application, if necessary, and runs some number of application tests. The trigger, execution, and capture are collectively referred to as a “build,” even if the execution does not specifically involve compiling software. If the script fails to complete successfully, as determined by the script itself, the build is said to fail.